在企業級 RAG 系統中，隨著 知識庫規模擴大 和 同時用戶數上升，系統常會遇到效能瓶頸，例如：

• 查詢延遲過高
• API 請求堆積
• 伺服器 CPU/記憶體過載

因此必須從 快取、異步、負載均衡 三個角度同時優化。

技術 1：快取（Caching）

核心原理

避免重複計算或查詢 - 把「熱門結果」暫存起來，下次相同請求直接回應。

使用情境

情境 1：重複查詢問題 省下 LLM 延遲與向量計算成本

• 問題：完全相同的問題（如「公司電話是多少？」）每次都要重新調用 LLM
• 解決方案：對完全一致的查詢，直接返回之前的 LLM 回答

情境 2：檢索結果快取 省下向量計算

• 問題：相同查詢每次都要重新做向量檢索和 chunk 提取
• 解決方案：快取 query → 相關文檔片段的結果

# 簡單範例
def get_answer(query):
    if cache.exists(query):
        return cache.get(query)  # 直接返回
    
    result = rag_pipeline(query)  # 完整 RAG 流程
    cache.set(query, result, ex=3600)  # 快取 1 小時
    return result

企業效益：減少 70-80% 的重複計算，延遲從 2 秒降到 0.1 秒

技術 2：異步處理（Asynchronous Processing）

核心原理

把耗時操作放入背景任務，用戶不用等待，系統也不會卡住。

使用情境

情境 1：文件上傳處理

• 問題：用戶上傳 100 頁的 PDF，需要等 3 分鐘處理完才能回應
• 解決方案：立即回覆「已接收」，向量化放背景慢慢做

情境 2：大批量資料更新

• 問題：企業每天有大量文檔需要入庫，如果同步處理會阻塞其他查詢請求

• 解決方案：異步處理文檔入庫，立即回應用戶，背景完成後新文檔可檢索，定期重建索引維持品質

  索引更新策略：

  • 即時操作：

    • 新增文檔：立即向量化並加入索引
    • 修改文檔：軟刪除舊版 + 加入新版
    • 刪除文檔：標記為已刪除（軟刪除）

  • 定期重建：

    • 重建頻率：每日凌晨、每週、或根據業務需求
    • 重建觸發條件：累積刪除/修改達到一定比例（如 10%）、檢索品質明顯下降、固定時間週期

  • 實際運作流程：
    白天：即時處理文檔變更（品質逐漸下降）
    ↓
    凌晨：重建乾淨的索引（恢復最佳品質）
    ↓
    新的一天：從最佳狀態重新開始

  • 平衡考量：即時性 vs 品質、用戶體驗 vs 系統資源、成本控制
    這種策略讓企業能接受「文檔更新後立即生效，但需定期優化」的模式，換取更好的系統穩定性和成本控制。

情境 3：報表生成

• 問題：生成月報需要 10 分鐘，用戶不能一直等
• 解決方案：背景生成，完成後通知用戶

# 異步任務範例
@app.task
def process_document(file_path):
    # 1. 文本提取
    # 2. 切分 chunks  
    # 3. 向量化
    # 4. 存入資料庫
    pass

# API 立即回應
def upload_file(file):
    process_document.delay(file.path)  # 丟給背景
    return {"status": "processing", "message": "檔案處理中"}

企業效益：用戶體驗提升，系統可支援更高併發

技術 3：負載均衡（Load Balancing）

核心原理

把請求分散到多台伺服器，避免單台機器過載。

使用情境

情境 1：高峰時段壓力

• 問題：上班時間查詢量激增，單台伺服器撐不住
• 解決方案：部署 3 台 RAG 伺服器，用 Nginx 分流

情境 2：資源隔離

• 問題：查詢服務和文檔處理服務在 GPU 記憶體、運算資源、系統記憶體上存在競爭，影響查詢回應時間
• 解決方案：查詢服務和文檔處理分機器部署，避免搶資源影響查詢速度

情境 3：容錯需求

• 問題：某台機器掛掉，整個服務就不能用
• 解決方案：多台機器維持 RAG 系統穩定

# Nginx 簡單配置
upstream rag_servers {
    server rag1:8000;
    server rag2:8000;
    server rag3:8000;
}

server {
    location /api {
        proxy_pass http://rag_servers;
    }
}

企業效益：系統穩定性提升，可承載更多用戶

實務搭配策略

小型系統（< 1000 用戶）

• 優先快取：Redis 存熱門查詢結果
• 單機部署即可

中型系統（1000-10000 用戶）

• 快取 + 異步：查詢快取 + 文件處理異步
• 開始考慮 2-3 台機器負載均衡

大型系統（> 10000 用戶）

• 三技術全用：多層快取 + 異步任務隊列 + 多機負載均衡
• 微服務架構，不同服務獨立擴展

效能提升預期

想想看

1. 在你的工作或生活中，有沒有遇過「等待太久」的情境？如果可以「快取」某些結果，你希望快取的是什麼？（例如：常用的資料、重複的工作流程）

2. 想像一個團隊同時要處理很多任務時，你覺得哪些事情適合「即時處理」，哪些事情適合「放到後面再處理」（異步）？

3. 如果你要主持一場大型活動，現場同時有上百人找你問問題，你會怎麼安排「分工」或「分流」來避免自己被壓垮？（這就是負載均衡的概念）